The present invention relates generally to the execution of scheduled jobs and more specifically to the oversight and time-adjustment of the execution of scheduled jobs.
In existing systems that execute scheduled jobs, these jobs are commonly referred to as batch processes. In some UNIX processing environments, these scheduled jobs are also referred to as chron jobs. These batch processes are typically executed at off-times when processing requirements for a main system are reduced. For example, batch processes may be performed during late night-time and early morning hours when system users are not accessing a central processing system. The processing system may then readily dedicate the processing resources for completing the batch processes or scheduled jobs.
Increased computing resources and system efficiencies have reduced the time-sensitive nature of batch processing. While many batch processes are run during off-peak hours, the timing of these processes are typically dictated by other means, such as the availability and time-sensitivity of the data being processed. For example, a batch process might be running a month-end report including billing information for multiple clients or customers. The scheduled execution of the job is based on the timing of the billing information being received in the processing system. In this example, the job is scheduled based on a reasonable determination of when the requisite billing information is available from the billing system.
Scheduled jobs are also complicated by the increased complexity of multiple processing systems. When a processing environment includes one or more processing systems capable of running the batch processes and multiple ancillary systems that provide the data for these jobs, problems can arise. If there is an error with any one of the multiple different processing systems in the processing environment, this may make the batch process incorrect. In addition to problems or errors in the ancillary system, there may also be concerns that these ancillary systems do not yet have complete and proper data sets, e.g. not all the requisite information is compiled yet. For example, if the batch process includes multiple invoices and one billing system does not have current invoice data, the scheduled job will run an improper report. In fact, the scheduled job will most likely have to be re-executed when the missing data is properly assembled or compiled. Improperly running scheduled job is not only extremely inefficient, but a significant waste of processing resources.
As the number of interdependent systems increases, there are also other concerns besides the integrity of the data used for the scheduled job. For example, if one system goes down for any reason, that may cause significant disruptions in the complete processing environment for one or more scheduled jobs, including further scheduled jobs that are dependent upon the generated data of previous jobs. As multi-processing environments globally interconnect, the potential for errors with jobs using improper increases.
In current processing systems, scheduled jobs are either executed or cancelled. If a job is scheduled for a predetermined time, that job is then executed at said time. Should there be concerns about the integrity of the data processing in the schedule job, a user must manually over-ride a job scheduling system to terminate the job. In some systems, a user must navigate multiple levels to delay or cancel the job. When a user manually resets an execution time for a particular job, this requires permanently resetting the defined execution time for the job. Current systems do not provide for a temporary one-time reset. Therefore, when this occurs, a user must thereupon re-reset the job execution time back to its original time after the job is executed.